ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group95c.txt/000005_icon-group-sender _Wed Sep 20 18:39:53 1995.msg

Internet Message Format | 1996-01-03 | 4KB

Received: by cheltenham.cs.arizona.edu; Thu, 21 Sep 1995 09:41:53 MST
To: [e-mail]
Date: 20 Sep 1995 18:39:53 GMT
From: [e-mail] (John Chambers)
Message-Id: <43pn5p$[e-mail]>
Organization: GTE Laboratories
Sender: [e-mail]
References: <43d0g9$[e-mail]>, <43fgn3$[e-mail]>, <[e-mail]>
Subject: Re: what to use instead of TCL or PERL
Errors-To: [e-mail]

In article <[e-mail]> [e-mail] () writes:
>J.M. Ivler ([e-mail]) wrote:
>
>|Consider the programmer as a carpenter. He has to sink a screw. Now he could
>|use a hammer to sink it, and it would work, but it would work much better
>|if he used a screwdriver. Additionally, the screw is a philips head. Now
>|he could use a flathead screwdriver, but wouldn't the better tool be a
>|philipshead screwdriver? Now, if he had only one screw to sink, he might
>|use a hand screwdriver, but he has 1000, so might it not be wise to
>|attach a philipshead screwdriver to a powertool to help?
>
>Carpenters often _do_ use  hammers to insert screws; they hit them in for most
>of  the distance and  then screw  them  in for  only the  last 1cm or so. Much
>faster, and it works!
>
>Know your tools, and use the appropriate _mix_ of tools!

As an example of yet another logical fallacy in the presuppositions
implied above:  Carpenters who have square-drive bits very often use
them to drive (mostly remove ;-) Phillips screws.  The smaller square
bits fit quite well into a Phillips screw's slots, and unlike the
Phillips bits, they don't tend to pop out so easily.  If you are
trying to remove a stuck or damaged screw, the square bit will usually
work better than the Phillips bit.

This is an example of the fallacy in the "obvious" advice to use the
appropriate tool for the job.  Few people would consider mixing bits
like this to be "appropriate" (in the usual sense of the term).  But
this is an example where the "wrong" tool actually does a better job
than the "right" tool.

To be more accurate, this is a case in which tool X does tool Y's job
better than tool Y does, despite the fact that X wasn't designed to do
Y's job.  Similar examples abound in the computing world.  Thus, csh
was designed as a C-like scripting language; it was supposed to be
better for writing scripts than sh.  There have been a lot of summaries
posted explaining why 1) (k)sh is a better scripting tool than csh, and
2) csh is a better interactive shell than (k)sh.  This is exactly the
opposite to what you'd expect from their design goals.

Another curious example I ran across a few years back:  I did a speed
test comparing various file-transfer packages across various networks.
One of the results was that, when uucp worked across tcp, it beat out
ftp by a *factor* of 3 to 4.  Now, uucp was designed to work across
poor-quality links like modems and phone lines; the tcp driver was a
late add-on.  On the other hand, ftp was designed to run on tcp.  So
how does uucp beat ftp so badly on ftp's "home court"?  A 10% difference
wouldn't be worth noticing, but how did ftp's authors blow the job
so badly as to lose by more than a factor of 2?  (Not only that,
but you don't have to hold uucp's hand like you do with ftp; it keeps
trying until it succeeds, and optionally tells you when it's done.  So
despite the fact that it's not interactive, it's much more user-friendly
than the interactive ftp.  Of course, ftp's problems won't be fixed, due
to the unwillingness of the Internet crowd to learn anything from things
like uucp. ;-)

The computer industry is full of examples of tools that do their job
poorly, while a tool not designed for the job does it better.

--
if (HEART(getenv("USER"),'C')) printf("Honk!\n");
print "Honk!\n" if &HEART($ENV{'USER'},'perl');
if {[HEART $env(USER)] == {tcl}} {button .h -text honk ; pack .h}
YOU 4TH HEART IF HONK THEN